No more 'operation completed successfully' in time_zone::get_info#3122
No more 'operation completed successfully' in time_zone::get_info#3122StephanTLavavej merged 1 commit intomicrosoft:mainfrom
time_zone::get_info#3122Conversation
When no mapping for a Unicode character existed in the target multi-byte code page, we just returned that error from `__std_fs_convert_wide_to_narrow`; instead, we additionally needed to `SetLastError()` after that call.
strega-nil-ms
added
the
decision needed
|
We discussed in the weekly maintainer meeting that this resolves the symptom, but not really the root cause of the problem. We're going to apply the PR as a clear improvement, and @strega-nil-ms will file a followup issue to investigate returning the full timezone spec instead of the localized abbreviation as a fallback when the localized abbreviation can't be transcoded from UTF-16 to the narrow encoding specified by the active code page. |
|
I observe that this affects the redist, but not in a way that involves synchronized header changes, so it should be fine. ✅ No header changes => no modules impact. |
|
I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed. |
|
Merge completed successfully! 😹 😸 😻 |
|
I guess I have spotted the root cause of the problem correct behavior would be no exception. Trouble begins when As a result, locale of the calendar becomes incompatible with The fix is trivial; just change the former to: The signature of |
5 participants
When no mapping for a Unicode character existed in the target multi-byte code page, we just returned that error from
__std_fs_convert_wide_to_narrow; instead, we additionally needed toSetLastError()after that call.Fixes #3097 (kind of)
The issue was that if the language of the system was not representable by the current code page, we would throw
GetLastError(); however, last error was never actually set.